Connection oriented point-to-point communication links, such as a Layer 2 Tunneling Protocol (L2TP) tunnel, are an increasingly common feature of network infrastructures. Tunnels are prearranged connections established by agreement between internet service providers (ISPs). See Request for Comment (RFC) 2661 and Layer Two Tunnelling Protocol (L2TP), A. Valencia, et al., draft-ietf-pppext-l2tp-16.txt, June 1999, herein incorporated by reference, available from the Internet Engineering Task Force (IETF) website.
FIG. 1 shows an architecture 100 involving an internet protocol (IP) network 70 to which a tunnel initiator 30 is linked via a network connection 32, a tunnel initiator 40 is linked via a network connection 42 and a tunnel endpoint 50 is linked via a network connection 52. A remote client 20 is linked to the tunnel initiator 30 via a communication link 22 that is tunneled through the IP network 70 via a tunnel connection 56 from the tunnel initiator 30 to the tunnel endpoint 50. Another remote client 24 is linked to the tunnel initiator 40 via a communication link 26 that is tunneled through the IP network 70 via a tunnel connection 66 from the tunnel initiator 40 to the tunnel endpoint 50. The tunnel endpoint device 50 is also connected to a Local Area Network (“LAN”) 80 via a network connection 54. A server device 84 is linked to LAN 80.
One example of a tunnel initiator or tunnel endpoint device is a network access server, such as that described in the patent to Dale M. Walsh et al., U.S. Pat. No. 5,528,595, which is fully incorporated by reference herein and describes an integrated network access server suitable for use in the present invention. Such a device has been commercialized widely by 3Com Corporation (previously U.S. Robotics Corp.) under the trade designation Total Control™ Enterprise Network Hub. Network access servers similar in functionality, architecture and design are available from other companies, including Ascend Communications, Livingston Enterprises, Multitech, and others. The invention is suitable for implementation in network access servers from the above companies, and other similar devices.
An L2TP tunnel typically provides a conduit for communications between a client device served by a tunnel initiator and a server device served by tunnel endpoint, i.e. tunnel connection 56 between tunnel initiator 30 and tunnel endpoint 50 that transports communication between remote client 20 and server 84. Typically, a single tunnel slot provides the communication link between a client and server.
When a client device, such as device 20 or 24, establishes a dial-up connection with a tunnel initiator (TI) 30 or 40, then the TI typically recognizes the client device as a tunnel client by means of an authentication protocol, such as RADIUS, see Request For Comment (RFC) 2138, herein incorporated by reference. An authentication, authorization and accounting (AAA) server 74, such as a RADIUS server, may be connected to the IP network 70 to provide AAA services to the tunnel initiators and other devices on the network. The authentication process can be adapted to provide an address for a tunnel endpoint device for the client. There exist other means for identifying a tunnel client, such as through the use of a mobile identification number (MIN) in mobile applications or, for protocols not directed toward mobile applications, the use of a Dial-up Number Information Service (DNIS) or Automatic Number identification (ANI), that can also be used to identify a tunnel endpoint for a client and establish a tunnel connection. Alternatively, the client device itself may provide the tunnel endpoint address. In still another approach, each TI may have a pre-constructed table containing entries that associate a client device identifier with a tunnel endpoint address value. Independent of how the tunnel endpoint address is obtained, the tunnel initiator will establish a tunnel connection to the tunnel endpoint device, e.g. the tunnel endpoint 50.
FIG. 2 is a protocol stack diagram 200 illustrating an example of the protocol relationships in a conventional tunnel structure. As is known in the art, the Open System Interconnection (“OSI”) model is used to describe computer networks. The OSI model consists of seven layers including from lowest-to-highest, a physical, data-link, network, transport, session, application and presentation layer. The physical layer, or layer 1, transmits bits over a communication link. The data link layer, or layer 2, transmits error free frames of data. The network layer, or layer 3, transmits and routes data packets. FIG. 2 illustrates an example of the protocol stacks in each of the remote client 20, tunnel initiator 30, tunnel endpoint 50, and server 84 for tunnel connection 56 of FIG. 1. Link 22 between the remote client 20 and tunnel initiator 30 can involve a wireless link protocol, such as the Radio Link Protocol (“RLP”), a dial-up type protocol, such as the Point-to-Point Protocol (PPP) or Serial Line Interface Protocol (SLIP), a network type protocol, such as the Media Access Control (“MAC”) protocol of Ethernet, or other types of links as the application demands. Thus, a layer 1 to layer 1 (L1) session is represented at the lowest level of the protocol stacks in FIG. 2 between the remote client 20 and tunnel initiator 30. Because the link between the remote client and tunnel initiator is typically a serial link, a serial data link protocol session exists at layer 2 (L2) between the remote client 20 and tunnel initiator 30.
When a tunnel is established from the tunnel initiator 30 to the tunnel endpoint 50, there are layer 1 (L1) and layer 2 (L2) sessions between the tunnel servers as well as an L2TP session that represents the tunnel connection 56 itself. Once the tunnel connection is established, a session between network layer peers, such as internet protocol (IP) peers, in the remote client 20 and tunnel endpoint 50 typically exists. A session also typically exists between transport layer peers in the remote client 20 and the server 84. Transport layer protocols such as Transmission Control Protocol (“TCP”) and User Datagram Protocol (“UDP”) are often used over IP in computer networks. The Transmission Control Protocol provides a connection-oriented, end-to-end reliable protocol designed to fit into a layered hierarchy of protocols that support multi-network applications. The User Datagram Protocol provides a transaction oriented datagram protocol, where delivery and duplicate packet protection are not guaranteed.
A second IP (IP2) and UDP (UDP2) peer relationship exists for routing of packets over the network 70 between the tunnel initiator 30 and the tunnel endpoint 50. In addition, a PPP peer relationship typically exists between the remote client 20 and the tunnel endpoint 50, where the PPP packets become the payload for the tunnel connection between the tunnel initiator 30 and tunnel endpoint 50. PPP is described in further detail in RFC 1661, herein incorporated by reference for all purposes.
Communication links from remote clients to tunnel initiators may take any of a variety of forms. If a remote client is connected to a public switched telephone network (“PSTN”), the communication links may include unshielded twisted pair of copper wires extending from a remote client's modem to a telephone company central office. While the quality of transmission over a conventional telephone line may vary, a typical telephone dial-up connection has a bandwidth of about 3 kHz and a signal-to-noise ratio of about 30 dB, thus, producing a bit rate of about 30 kbps.
Therefore, due to the limited bit rate, the telephone dial-up connections that are tunneled from a remote client to a tunnel endpoint typically suffer on the performance throughput. To overcome the throughput limitations of the telephone dial-up connections, one solution includes compression of data at the remote client prior to transmission of the data over a tunnel to a tunnel endpoint that, upon a receipt of the compressed data, decompresses the received data. However, the number of tunnel connections terminating at the tunnel endpoint is constantly growing, and it typically ranges from a few hundred to a few thousand tunnel connections terminating on the tunnel endpoint.
During a typical process of establishing a point-to-point communication link between the remote client 20 and the tunnel endpoint 50, the remote client 20 may negotiate compression and encryption parameters with the tunnel endpoint 50. The protocol stack of the remote client 20 typically includes a compression negotiator and a compression engine in the PPP stack, as illustrated in FIG. 2, to negotiate compression parameters with a compression negotiator on the tunnel endpoint 50. In such an embodiment, in addition to the compression negotiator, the tunnel endpoint 50 includes a compression engine that performs compression and encryption on the point-to-point communication link between the remote client 20 and the tunnel endpoint 50. However, compressing and decompressing data for many tunnel connections on the tunnel endpoint presents a heavy computational load that prevents the tunnel endpoint from supporting a large number of tunnel connections. As a result, the tunnel endpoint typically rejects any attempt by the client device to negotiate a communication link that employs compression or encryption.
As is also known in the art, Layer 2 point-to-point data transport typically uses an unreliable communication mechanism, e.g. UDP, and does not guarantee a reliable sequenced delivery of packets. Further, since the Layer 2 point-to-point assumes a sequence in data delivery, out of sequence packets and packets lost during transmission adversely affect the compression and encryption mechanism. Thus, compressing packets at a tunnel endpoint does not result in a good point-to-point compression performance. Due to these reasons, the tunnel endpoints typically reject user requests to perform the point-to-point compression and encryption and, consequently, the end user connections suffer low-level throughputs.
Thus, the need remains for a system and method for increasing remote clients' data throughput over tunnel connections.